Skip Headers

Oracle® Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide 10g Release 2 (10.2) for Linux Part Number B14203-06 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# 2 Pre-Installation Tasks

This chapter describes the system configuration tasks that you must complete before you start Oracle Universal Installer. It includes information about the following tasks:

- Understanding and Using Cluster Verification Utility

- Logging In to the System as root

- Creating Required Operating System Groups and User

- Configuring the oracle User's Environment

- Checking the Hardware Requirements

- Checking the Network Requirements

- Checking the Network Setup with CVU

- Identifying Software Requirements

- Checking the Software Requirements

- Configuring Kernel Parameters

- Checking the Hardware and Operating System Setup with CVU

- Checking the Operating System Requirements Setup with CVU

- Identifying Required Software Directories

- Identifying or Creating an Oracle Base Directory

- Creating the Oracle Clusterware Home Directory

- Checking the Configuration of the Hangcheck-timer Module

- Running the rootpre.sh Script for Installations on x86 (64-bit) Systems

- Stopping Existing Oracle Processes for Upgrades or Co-existing Databases

## 2.1 Understanding and Using Cluster Verification Utility

Cluster Verification Utility (CVU) is a tool that performs system checks. This guide provides CVU commands to assist you with confirming that your system is properly configured for Oracle Clusterware and Oracle Real Application Clusters installation.

This section describes the following topics:

- Using CVU to Determine if Installation Prerequisites are Complete

- Entering Cluster Verification Utility Commands

- Using the Cluster Verification Utility Help

- Using Cluster Verification Utility with Oracle 10g Release 1

- Verbose Mode and "Unknown" Output

### 2.1.1 Entering Cluster Verification Utility Commands

To enter a CVU command, use the following syntax:

    $ /mountpoint/crs/Disk1/cluvfy/runcluvfy.sh options

In the preceding syntax example, the variable mountpoint represents the mountpoint path for the installation media, and the variable `options` represents the CVU command options that you select. For example:

    /dev/dvdrom/crs/Disk1/cluvfy/runcluvfy.sh comp nodereach -n node1,node2 -verbose

By default, when you enter a CVU command, CVU provides a summary of the test. During pre-installation, Oracle recommends that you obtain detailed output by using the `-verbose` argument with the CVU command. The `-verbose` argument produces detailed output of individual checks. Where applicable, it shows results for each node in a tabular layout.

### 2.1.2 Using CVU to Determine if Installation Prerequisites are Complete

You can use CVU to determine which system prerequisites for installation are already completed. Use this option if you are installing Oracle 10g Release 2 (10.2) on a system with a pre-existing Oracle software installation. In using this option, note the following:

- You must complete the prerequisites for using CVU

- CVU can assist you by finding pre-installation steps that need to be completed, but it cannot perform pre-installation tasks

Use the following syntax to determine what pre-installation steps are completed, and what pre-installation steps must be performed

    /mountpoint/crs/Disk1/cluvfy/runcluvfy.sh stage -pre crsinst -n node_list

In the preceding syntax example, replace the variable `mountpoint` with the installation media mountpoint, and replace the variable `node_list` with the names of the nodes in your cluster, separated by commas.

For example, for a cluster with mountpoint /dev/dvdrom/, and with nodes `node1`, `node2`, and `node3`, enter the following command:

    /dev/dvdrom/crs/Disk1/cluvfy/runcluvfy.sh stage -pre crsinst -n node1,node2,node3

Review the CVU report, and proceed to the sections of the pre-installation chapter to complete additional steps as needed.

### 2.1.3 Using the Cluster Verification Utility Help

The `cluvfy` commands have context-sensitive help that shows correct syntax usage based on the command line arguments that you enter.

If you enter an invalid CVU command, then CVU shows the correct usage for that command. For example, if you type `runcluvfy.sh stage -pre dbinst`, then CVU shows the correct syntax for the database pre-installation checks that CVU performs with the `dbinst` stage option. The following is a list of context help commands.

- `cluvfy`: CVU displays high-level generic usage text describing the stage and component syntax.

- `cluvfy -help`: CVU displays detailed CVU command information.

- `cluvfy comp -list`: CVU displays a list of components that can be checked, and brief descriptions of how each component is checked.

- `cluvfy comp -help`: CVU displays detailed syntax for each of the valid component checks.

- `cluvfy stage -list`: CVU displays a list of valid stages.

- `cluvfy stage -help`: CVU displays detailed syntax for each of the valid stage checks.

### 2.1.4 Using Cluster Verification Utility with Oracle 10g Release 1

You can use CVU on the Oracle 10g Release 2 (10.2) media to check system requirements for Oracle 10g Release 1 (10.1) installations. To use CVU to check 10. 1 installations, append the command flag -r 10gR1 to the standard CVU system check commands.

For example, to perform a verification check for a Cluster Ready Services 10. 1 installation, on a system where the media mountpoint is /dev/dvdrom/, and the cluster nodes are `node1`, `node2`, and `node3`, enter the following command:

    /dev/dvdrom/crs/Disk1/cluvfy/runcluvfy.sh stage -pre crsinst -n node1,node2,node3 -r 10gR1

### 2.1.5 Verbose Mode and "Unknown" Output

If you run CVU using the `-verbose` argument, and a CVU command responds with `UNKNOWN` for a particular node, then this is because the CVU cannot determine whether a check passed or failed. The following is a list of possible causes for an "Unknown" response:

- The node is down

- Executables required by CVU are missing in the CRS_home `/bin` or Oracle home directory

- The user account starting CVU does not have privileges to run common operating system executables on the node

- The node is missing an operating system patch, or a required package

- The node has exceeded the maximum number of processes or maximum number of open files, or there is a problem with IPC segments, such as shared memory or semaphores

## 2.2 Logging In to the System as root

Before you install the Oracle software, you must complete several tasks as the `root` user. To log in as the `root` user, complete one of the following procedures:

- If you are installing the software from an X Window System workstation or X terminal, then:

  1. Start a local terminal session, for example, an X terminal (`xterm`).

  2. If you are not installing the software on the local system, then enter the following command to enable remote hosts to display X applications on the local X server:

         $ xhost + hostname

     The hostname is the name of the local host.

  3. If you are not installing the software on the local system, then use the `ssh`, `rlogin`, or `telnet` command to connect to the system where you want to install the software:

         $ telnet remote_host

  4. If you are not logged in as the `root` user, then enter the following command to switch the user to `root`:

         $ su - root
         password:
         #

- If you are installing the software from a PC or other system with X server software installed, then:

  Note: If necessary, refer to your X server documentation for more information about completing this procedure. Depending on the X server software that you are using, you may need to complete the tasks in a different order.

  1. Start the X server software.

  2. Configure the security settings of the X server software to permit remote hosts to display X applications on the local system.

  3. Connect to the remote system where you want to install the software and start a terminal session on that system, for example, an X terminal (`xterm`).

  4. If you are not logged in as the `root` user on the remote system, then enter the following command to switch user to `root`:

         $ su - root
         password:
         #

## 2.3 Creating Required Operating System Groups and User

Depending on whether this is the first time Oracle software is being installed on this system and on the products that you are installing, you may need to create several operating system groups and an operating system user account.

The following operating system groups and user are required if you are installing Oracle Database:

- The OSDBA group (typically, `dba`)

  You must create this group the first time you install Oracle Database software on the system. This group identifies operating system user accounts that have database administrative privileges (the SYSDBA privilege). The default name for this group is `dba`.

  If you want to specify a group name other than the default `dba` group, then you must choose the Custom installation type to install the software or start Oracle Universal Installer as a user that is not a member of this group. In this case, Oracle Universal Installer prompts you to specify the name of this group.

- The OSOPER group (typically, `oper`)

  This is an optional group. Create this group if you want a separate group of operating system users to have a limited set of database administrative privileges (the SYSOPER privilege). By default, members of the OSDBA group also have the SYSOPER privilege.

  If you want to specify a separate OSOPER group, other than the default `dba` group, then you must choose the Custom installation type to install the software or start Oracle Universal Installer as a user that is not a member of the `dba` group. In this case, Oracle Universal Installer prompts you to specify the name of this group. The usual name chosen for this group is `oper`.

- An unprivileged user

  Verify that the unprivileged user `nobody` exists on the system. The `nobody` user must own the external jobs (extjob) executable after the installation.

The following operating system group and user are required for all installations:

- The Oracle Inventory group (typically, `oinstall`)

  You must create this group the first time you install Oracle software on the system. The usual name chosen for this group is `oinstall`. This group owns the Oracle Inventory, which is a catalog of all Oracle software installed on the system.

  Note: If Oracle software is already installed on the system, then the existing Oracle Inventory group must be the primary group of the operating system user that you use to install new Oracle software. The following sections describe how to identify an existing Oracle Inventory group.

- The Oracle software owner user (typically, `oracle`)

  You must create this user the first time you install Oracle software on the system. This user owns all of the software installed during the installation. The usual name chosen for this user is `oracle`. This user must have the Oracle Inventory group as its primary group. It must also have the OSDBA and OSOPER groups as secondary groups. In Oracle documentation, when this user account is referred to, it is called the `oracle` user.

A single Oracle Inventory group is required for all installations of Oracle software on the system. After the first installation of Oracle software, you must use the same Oracle Inventory group for all subsequent Oracle software installations on that system. However, you can choose to create different Oracle software owner users, OSDBA groups, and OSOPER groups (other than `oracle`, `dba`, and `oper`) for separate installations. By using different groups for different installations, members of these different groups have DBA privileges only on the associated databases rather than on all databases on the system.

See Also: Oracle Database Administrator's Reference for UNIX Systems and Oracle Database Administrator's Guide for more information about the OSDBA and OSOPER groups and the SYSDBA and SYSOPER privileges

The following sections describe how to create the required operating system user and groups:.

- Creating the Oracle Inventory Group

- Creating the OSDBA Group

- Creating an OSOPER Group (Optional)

- Creating the Oracle Software Owner User

- Verifying That the User nobody Exists

- Creating Identical Users and Groups on Other Cluster Nodes

- Configuring SSH on All Cluster Nodes

Note: The following sections describe how to create local users and groups. As an alternative to creating local users and groups, you can create the appropriate users and groups in a directory service, such as Network Information Services (NIS). For information about using directory services, contact your system administrator or refer to your operating system documentation.

### 2.3.1 Creating the Oracle Inventory Group

Oracle Universal Installer (OUI) helps you to choose a group to use as the Oracle Inventory group. If you have an existing Oracle Inventory group, then provide this group name and path when prompted.

The following subsections describe how to determine the Oracle Inventory group name, if it exists, and how to create it if necessary.

Determining If the Oracle Inventory Exists

When you install Oracle software on the system for the first time, Oracle Universal Installer creates the `oraInst.loc` file. This file identifies the name of the Oracle Inventory group (typically, `oinstall`), and the path of the Oracle Inventory directory.

If you have an existing Oracle Inventory, then ensure that you use the same Oracle Inventory for all Oracle software installations.

If you do not have an existing Oracle Inventory, then you should create an Oracle Inventory group.

To determine whether you have an Oracle Inventory on your system:

On x86 or Itanium systems, enter the following command:

    # more /etc/oraInst.loc

On IBM zSeries based systems, enter the following command:

    # more /var/opt/oracle/oraInst.loc

If the `oraInst.loc` file exists, then the output from this command is similar to the following:

    inventory_loc=/u01/app/oracle/oraInventory
    inst_group=oinstall

In the previous output example:

- The `inventory_loc` group shows the location of the Oracle Inventory

- The `inst_group` parameter shows the name of the Oracle Inventory group (in this example, `oinstall`).

Creating the Oracle Inventory Group If an Oracle Inventory Does Not Exist

If the `oraInst.loc` file does not exist, then create the Oracle Inventory group by entering a command similar to the following:

    # /usr/sbin/groupadd oinstall

### 2.3.2 Creating the OSDBA Group

You must create an OSDBA group in the following circumstances:

- An OSDBA group does not exist, for example, if this is the first installation of Oracle Database software on the system

- An OSDBA group exists, but you want to give a different group of operating system users database administrative privileges for a new Oracle Database installation

If the OSDBA group does not exist or if you require a new OSDBA group, then create it as follows. In the following procedure, use the group name `dba` unless a group with that name already exists:

    # /usr/sbin/groupadd dba

### 2.3.3 Creating an OSOPER Group (Optional)

Create an OSOPER group only if you want to identify a group of operating system users with a limited set of database administrative privileges (SYSOPER operator privileges). For most installations, it is sufficient to create only the OSDBA group. If you want to use an OSOPER group, then you must create it in the following circumstances:

- If an OSOPER group does not exist; for example, if this is the first installation of Oracle Database software on the system

- If an OSOPER group exists, but you want to give a different group of operating system users database operator privileges in a new Oracle installation

If you require a new OSOPER group, then create it as follows. In the following, use the group name `oper` unless a group with that name already exists.

    # /usr/sbin/groupadd oper

### 2.3.4 Creating the Oracle Software Owner User

You must create an Oracle software owner user in the following circumstances:

- If an Oracle software owner user does not exist; for example, if this is the first installation of Oracle software on the system

- If an Oracle software owner user exists, but you want to use a different operating system user, with different group membership, to give database administrative privileges to those groups in a new Oracle Database installation

Note: If you intend to use multiple Oracle software owners for different Oracle homes, then you should create a separate Oracle software owner for Oracle Clusterware, and install Oracle Clusterware using the Oracle Clusterware software owner.

Determining if an Oracle Software Owner User Exists

To determine whether an Oracle software owner user named `oracle` exists, enter the following command:

    # id oracle

If the `oracle` user exists, then the output from this command is similar to the following:

    uid=440(oracle) gid=200(oinstall) groups=201(dba),202(oper)

If the user exists, then determine whether you want to use the existing user, or create another `oracle` user. If you want to use the existing user, then ensure that the user's primary group is the Oracle Inventory group and that it is a member of the appropriate OSDBA and OSOPER groups. Refer to one of the following sections for more information:

Note: If necessary, contact your system administrator before using or modifying an existing user.

- To modify an existing user, refer to the "Modifying an Existing Oracle Software Owner User" section.

- To create a user, refer to the following section.

Creating an Oracle Software Owner User

If the Oracle software owner user does not exist, or if you require a new Oracle software owner user, then create it as follows. In the following procedure, use the user name `oracle` unless a user with that name already exists.

1. To create the `oracle` user, enter a command similar to the following:

       # /usr/sbin/useradd -u 200 -g oinstall -G dba[,oper] oracle

   In the preceding command:

   - The -u option specifies the user ID. Using this command flag is optional, as you can allow the system to provide you with an automatically generated user ID number. However, you must make note of the `oracle` user ID number, as you require it later during pre-installation.

   - The `-g` option specifies the primary group, which must be the Oracle Inventory group--for example, `oinstall`

   - The `-G` option specifies the secondary groups, which must include the OSDBA group, and, if required, the OSOPER group. For example: `dba`, or `dba,oper`

2. Set the password of the `oracle` user:

       # passwd oracle

   Refer to the section "Verifying That the User nobody Exists".

Modifying an Existing Oracle Software Owner User

If the `oracle` user exists, but its primary group is not `oinstall`, or it is not a member of the appropriate OSDBA or OSOPER groups, then enter a command similar to the following to modify it. Specify the primary group using the `-g` option and any required secondary group using the `-G` option:

    # /usr/sbin/usermod -g oinstall -G dba[,oper] oracle

Repeat this procedure on all of the other nodes in the cluster.

### 2.3.5 Verifying That the User nobody Exists

Before installing the software, complete the following procedure to verify that the user nobody exists on the system:

1. To determine if the user exists, enter the following command:

       # id nobody

   If this command displays information about the `nobody` user, then you do not have to create that user.

2. If the `nobody` user does not exist, then enter the following command to create it:

       # /usr/sbin/useradd nobody

3. Repeat this procedure on all the other nodes in the cluster.

### 2.3.6 Creating Identical Users and Groups on Other Cluster Nodes

Note: You must complete the following procedures only if you are using local users and groups. If you are using users and groups defined in a directory service such as NIS, then they are already identical on each cluster node.

The Oracle software owner user and the Oracle Inventory, OSDBA, and OSOPER groups must exist and be identical on all cluster nodes. To create these identical users and groups, you must identify the user ID and group IDs assigned them on the node where you created them, then create the user and groups with the same name and ID on the other cluster nodes.

Identifying the User and Group IDs

To determine the user ID (UID) of the Oracle software owner user and the group IDs (GID) of the Oracle Inventory, OSDBA, and OSOPER groups, follow these steps:

1. Enter following command:

       # id oracle

   The output from this command is similar to the following:

       uid=440(oracle) gid=200(oinstall) groups=201(dba),202(oper)

2. From the output, identify the user ID (UID) for the `oracle` user and the group identities (GIDs) for the groups to which it belongs.

Creating the User and Groups on the Other Cluster Nodes

To create the user and groups on the other cluster nodes, repeat the following procedure on each node:

1. Log in to the next cluster node as `root`.

2. Enter commands similar to the following to create the `oinstall` and `dba` groups, and if required, the `oper` group. Use the `-g` option to specify the correct GID for each group.

       # /usr/sbin/groupadd -g 200 oinstall
       # /usr/sbin/groupadd -g 201 dba
       # /usr/sbin/groupadd -g 202 oper

   Note: If the group already exists, then use the `groupmod` command to modify it if necessary. If you cannot use the same group ID for a particular group on this node, then view the `/etc/group` file on all nodes to identify a group ID that is available on every node. You must then specify that ID for the group on all of the nodes.

3. To create the `oracle` user, enter a command similar to the following:

       # /usr/sbin/useradd -u 200 -g oinstall -G dba[,oper] oracle

   In the preceding command:

   - The `-u` option specifies the user ID, which must be the user ID that you identified in the previous subsection

   - The `-g` option specifies the primary group, which must be the Oracle Inventory group, for example `oinstall`

   - The `-G` option specifies the secondary groups, which must include the OSDBA group and if required, the OSOPER group. For example: `dba` or `dba,oper`

     Note: If the `oracle` user already exists, then use the `usermod` command to modify it if necessary. If you cannot use the same user ID for the `oracle` user on this node, then view the `/etc/passwd` file on all nodes to identify a user ID that is available on every node. You must then specify that ID for the user on all of the nodes.

4. Set the password of the `oracle` user:

       # passwd oracle

### 2.3.7 Configuring SSH on All Cluster Nodes

Before you install and use Oracle Real Application clusters, you must configure secure shell (SSH) for the `oracle` user on all cluster nodes. Oracle Universal Installer uses the `ssh` and `scp` commands during installation to run remote commands on and copy files to the other cluster nodes. You must configure SSH so that these commands do not prompt for a password.

Note: This section describes how to configure OpenSSH version 3. If SSH is not available, then Oracle Universal Installer attempts to use `rsh` and `rcp` instead. However, these services are disabled by default on most Linux systems. To determine if SSH is running, enter the following command:
    $ pgrep sshd
If SSH is running, then the response to this command is process ID numbers. To find out more about SSH, enter the following command:
    $ man ssh

#### 2.3.7.1 Configuring SSH on Cluster Member Nodes

To configure SSH, you must first create RSA and DSA keys on each cluster node, and then copy the keys from all cluster node members into an authorized keys file on each node. To do this task, complete the following steps:

Create RSA and DSA keys on each node: Complete the following steps on each node:

1. Log in as the `oracle` user.

2. If necessary, create the `.ssh` directory in the `oracle` user's home directory and set the correct permissions on it:

       $ mkdir ~/.ssh
       $ chmod 700 ~/.ssh

3. Enter the following commands to generate an RSA key for version 2 of the SSH protocol:

       $ /usr/bin/ssh-keygen -t rsa

   At the prompts:

   - Accept the default location for the key file.

   - Enter and confirm a pass phrase that is different from the `oracle` user's password.

   This command writes the public key to the `~/.ssh/id_rsa.pub` file and the private key to the `~/.ssh/id_rsa` file. Never distribute the private key to anyone.

4. Enter the following commands to generate a DSA key for version 2 of the SSH protocol:

       $ /usr/bin/ssh-keygen -t dsa

   At the prompts:

   - Accept the default location for the key file

   - Enter and confirm a pass phrase that is different from the `oracle` user's password

   This command writes the public key to the `~/.ssh/id_dsa.pub` file and the private key to the `~/.ssh/id_dsa` file. Never distribute the private key to anyone.

Add keys to an authorized key file: Complete the following steps:

1. On the local node, determine if you have an authorized key file (`~/.ssh/authorized_keys`). If the authorized key file already exists, then proceed to step 2. Otherwise, enter the following commands:

       $ touch ~/.ssh/authorized_keys
       $ cd ~/.ssh
       $ ls

   You should see the `id_dsa.pub` and `id_rsa.pub` keys that you have created.

2. Using SSH, copy the contents of the `~/.ssh/id_rsa.pub` and `~/.ssh/id_dsa.pub` files to the file `~/.ssh/authorized_keys`, and provide the `oracle` user password as prompted. This process is illustrated in the following syntax example with a two-node cluster, with nodes `node1` and `node2`, where the `oracle` user path is `/home/oracle:`

       [oracle@node1 .ssh]$ ssh node1 cat /home/oracle/.ssh/id_rsa.pub >> authorized_keys
       oracle@node1's password:
       [oracle@node1 .ssh]$ ssh node1 cat /home/oracle/.ssh/id_dsa.pub >> authorized_keys
       [oracle@node1 .ssh$ ssh node2 cat /home/oracle/.ssh/id_rsa.pub >> authorized_keys
       oracle@node2's password:
       [oracle@node1 .ssh$ ssh node2 cat /home/oracle/.ssh/id_dsa.pub >>authorized_keys
       oracle@node2's password:

   Note: Repeat this process for each node in the cluster.

3. Use SCP (Secure Copy) or SFTP (Secure FTP) to copy the `authorized_keys` file to the `oracle` user .ssh directory on a remote node. The following example is with SCP, on a node called node2, where the `oracle` user path is `/home/oracle`:

       [oracle@node1 .ssh]scp authorized_keys node2:/home/oracle/.ssh/

4. Repeat step 2 and 3 for each cluster node member. When you have added keys from each cluster node member to the authorized_keys file on the last node you want to have as a cluster node member, then use SCP to copy the complete authorized_keys file back to each cluster node member

   Note: the `oracle` user's `/.ssh/authorized_keys` file on every node must contain the contents from all of the `/.ssh/id_rsa.pub` and `/.ssh/id_dsa.pub` files that you generated on all cluster nodes.

5. Change the permissions on the `oracle` user's `/.ssh/authorized_keys` file on all cluster nodes:

       $ chmod 600 ~/.ssh/authorized_keys

   At this point, if you use `ssh` to log in to or run a command on another node, you are prompted for the pass phrase that you specified when you created the DSA key.

#### 2.3.7.2 Enabling SSH User Equivalency on Cluster Member Nodes

To enable Oracle Universal Installer to use the `ssh` and `scp` commands without being prompted for a pass phrase, follow these steps:

1. On the system where you want to run Oracle Universal Installer, log in as the `oracle` user.

2. Enter the following commands:

       $ exec /usr/bin/ssh-agent $SHELL
       $ /usr/bin/ssh-add

3. At the prompts, enter the pass phrase for each key that you generated.

   If you have configured SSH correctly, then you can now use the `ssh` or `scp` commands without being prompted for a password or a pass phrase.

4. If you are on a remote terminal, and the local node has only one visual (which is typical), then use the following syntax to set the DISPLAY environment variable:

   Bourne, Korn, and Bash shells

       $ export DISPLAY=hostname:0

   C shell:

       $ setenv DISPLAY 0

   For example, if you are using the Bash shell, and if your hostname is `node1`, then enter the following command:

       $ export DISPLAY=node1:0

5. To test the SSH configuration, enter the following commands from the same terminal session, testing the configuration of each cluster node, where `nodename1`, `nodename2`, and so on, are the names of nodes in the cluster:

       $ ssh nodename1 date
       $ ssh nodename2 date
           .
           .
           .

   These commands should display the date set on each node.

   If any node prompts for a password or pass phrase, then verify that the `~/.ssh/authorized_keys` file on that node contains the correct public keys.

   If you are using a remote client to connect to the local node, and you see a message similar to "Warning: No xauth data; using fake authentication data for X11 forwarding," then this means that your authorized keys file is configured correctly, but your ssh configuration has X11 forwarding enabled. To correct this, proceed to step 6.

   Note: The first time you use SSH to connect to a node from a particular system, you may see a message similar to the following:
       The authenticity of host 'node1 (140.87.152.153)' can't be established.
       RSA key fingerprint is 7z:ez:e7:f6:f4:f2:4f:8f:9z:79:85:62:20:90:92:z9.
       Are you sure you want to continue connecting (yes/no)?
   Enter `yes` at the prompt to continue. You should not see this message again when you connect from this system to that node. If you see any other messages or text, apart from the date, then the installation can fail. Make any changes required to ensure that only the date is displayed when you enter these commands. You should ensure that any parts of login scripts that generate any output, or ask any questions, are modified so that they act only when the shell is an interactive shell.

6. To ensure that X11 forwarding will not cause the installation to fail, create a user-level SSH client configuration file for the Oracle software owner user, as follows:

   1. Using any text editor, edit or create the `~oracle/.ssh/config` file.

   2. Make sure that the ForwardX11 attribute is set to `no`. For example:

          Host *
                ForwardX11 no

7. You must run Oracle Universal Installer from this session or remember to repeat steps 2 and 3 before you start Oracle Universal Installer from a different terminal session.

#### 2.3.7.3 Preventing Oracle Clusterware Installation Errors Caused by stty Commands

During an Oracle Clusterware installation, Oracle Universal Installer uses SSH (if available) to run commands and copy files to the other nodes. During the installation, hidden files on the system (for example, .bashrc or .cshrc) will cause installation errors if they contain stty commands.

To avoid this problem, you must modify these files to suppress all output on STDERR, as in the following examples:

- Bourne, Bash, or Korn shell:

      if [ -t 0 ]; then
         stty intr ^C
      fi

- C shell:

      test -t 0
      if ($status == 0) then
         stty intr ^C
      endif

  Note: When SSH is not available, the Installer uses the `rsh` and `rcp` commands instead of `ssh` and `scp`. If there are hidden files that contain stty commands that are loaded by the remote shell, then OUI indicates an error and stops the installation.

## 2.4 Configuring the oracle User's Environment

You run Oracle Universal Installer from the `oracle` account. However, before you start Oracle Universal Installer you must configure the environment of the `oracle` user.

To configure the environment, you must:

- Set the default file mode creation mask (umask) to 022 in the shell startup file

- Set the DISPLAY, ORACLE_BASE, and ORACLE_HOME environment variables in preparation for the Oracle Clusterware installation

You should also ensure that the PATH variable contains `$ORACLE_HOME/bin` before `/usr/X11R6/bin`

To set the `oracle` user's environment, follow these steps:

1. Start a new terminal session; for example, start an X terminal (`xterm`).

2. Enter the following command to ensure that X Window applications can display on this system:

       $ xhost + hostname

   The hostname is the name of the local host.

3. If you are not already logged in to the system where you want to install the software, then log in to that system as the `oracle` user.

4. If you are not logged in as the `oracle` user, then switch user to `oracle`:

       $ su - oracle

5. To determine the default shell for the `oracle` user, enter the following command:

       $ echo $SHELL

6. Open the `oracle` user's shell startup file in any text editor:

   Note: On Red Hat Linux, `.bash_profile` is the user startup file for the Bash shell.

   - Bourne shell (`sh`), Bash shell (`bash`) or Korn shell (`ksh`):

         % vi .bash_profile

   - C shell (`csh` or `tcsh`):

         % vi .login

7. Enter or edit the following line, specifying a value of 022 for the default file mode creation mask:

       umask 022

8. If the `ORACLE_SID`, `ORACLE_HOME`, or `ORACLE_BASE` environment variable is set in the file, then remove the appropriate lines from the file.

9. Save the file, and exit from the text editor.

10. To run the shell startup script, enter one of the following commands:

    - Bash shell on Red Hat Enterprise Linux:

          $ . ./.bash_profile

    - Bourne, Bash, or Korn shell:

          $ . ./.profile

    - C shell:

          % source ./.login

11. If you are not installing the software on the local system, then enter a command similar to the following to direct X applications to display on the local system:

    - Bourne, Bash, or Korn shell:

          $ DISPLAY=local_host:0.0 ; export DISPLAY

    - C shell:

          % setenv DISPLAY local_host:0.0

    In this example, `local_host` is the host name or IP address of the system that you want to use to display Oracle Universal Installer (your workstation or PC).

12. If you determined that the `/tmp` directory has less than 400 MB of free disk space, then identify a file system with at least 400 MB of free space and set the `TEMP` and `TMPDIR` environment variables to specify a temporary directory on this file system:

    Note: You cannot use a shared file system as the location of the temporary file directory (typically `/tmp`) for RAC installation. If you place `/tmp` on a shared file system, then the installation fails.

    1. Use the `df -h` command to identify a suitable file system with sufficient free space.

    2. If necessary, enter commands similar to the following to create a temporary directory on the file system that you identified, and set the appropriate permissions on the directory:

           $ su - root
           # mkdir /mount_point/tmp
           # chmod 775 /mount_point/tmp
           # exit

    3. Enter commands similar to the following to set the TEMP and TMPDIR environment variables:

       - Bourne, Bash, or Korn shell:

             $ TEMP=/mount_point/tmp
             $ TMPDIR=/mount_point/tmp
             $ export TEMP TMPDIR

       - C shell:

             % setenv TEMP /mount_point/tmp
             % setenv TMPDIR /mount_point/tmp

### 2.4.1 Installing the cvuqdisk Package for Linux

If you are using Red Hat or SUSE Linux, then you must download and install the operating system package `cvuqdisk`. Without `cvuqdisk`, CVU is unable to discover shared disks, and you receive the error message "Package cvuqdisk not installed" when you run CVU. Use the cvuqdisk rpm for your hardware (`i386`, or for Itanium, `ia64`).

To install the `cvuqdisk` RPM, complete the following procedure:

Note: If you prefer, you can choose to disable CVU shared disk checks by adding the following line to the file `CRS_home``/cv/admin/cvuconfig`:
    CV_RAW_CHECK_ENABLED=FALSE

1. Locate the `cvuqdisk` RPM package, which is in the directory `clusterware/rpm` on the installation media. If you have already installed Oracle Clusterware, then it is located in the directory `CRS_home``/rpm`.

2. Copy the `cvuqdisk` package to each node on the cluster. You should ensure that each node is running the same version of Linux.

3. Log in as root.

4. Using the following command, check to see if you have an existing version of the `cvuqdisk` package:

       # rpm -qi cvuqdisk

   If you have an existing version, then enter the following command to de-install the existing version:

       rpm -e cvuqdisk

5. Set the environment variable CVUQDISK_GRP to point to the group that will own cvuqdisk, typically `oinstall`.

6. Use the following command to install the `cvuqdisk` package:

       rpm -iv cvuqdisk-1.0.1-1.rpm

## 2.5 Checking the Hardware Requirements

Each system must meet the following minimum hardware requirements:

- At least 1 GB of physical RAM

- Swap space equivalent to the multiple of the available RAM, as indicated in the following table:

  Available RAM | Swap Space Required
  --- | ---
  Between 1 GB and 2 GB | 1.5 times the size of RAM
  More than 2 GB | Equal to the size of RAM

- 400 MB of disk space in the `/tmp` directory

- Up to 4 GB of disk space for the Oracle software, depending on the installation type and platform

- 1.2 GB of disk space for a preconfigured database that uses file system storage (optional)

  Note: The disk space requirement for databases that use Automatic Storage Management or raw device storage is described later in this chapter.

  Additional disk space, either on a file system or in an Automatic Storage Management disk group, is required for the flash recovery area if you choose to configure automated backups.

To ensure that each system meets these requirements, follow these steps:

1. To determine the physical RAM size, enter the following command:

       # grep MemTotal /proc/meminfo

   If the size of the physical RAM installed in the system is less than the required size, then you must install more memory before continuing.

2. To determine the size of the configured swap space, enter the following command:

       # grep SwapTotal /proc/meminfo

   If necessary, refer to your operating system documentation for information about how to configure additional swap space.

3. To determine the amount of disk space available in the `/tmp` directory, enter the following command:

   -     # df -k /tmp

   This command displays disk space in 1 kilobyte blocks. On most systems, you can use the df command with the -h flag (df -h) to display output in "human-readable" format, such as "24G" and "10M." If there is less than 400 MB of disk space available in the `/tmp` directory (less than 4194304 1-k blocks), then complete one of the following steps:

   - Delete unnecessary files from the `/tmp` directory to make available the disk space required.

   - Set the TEMP and TMPDIR environment variables when setting the `oracle` user's environment (described later).

   - Extend the file system that contains the `/tmp` directory. If necessary, contact your system administrator for information about extending file systems.

4. To determine the amount of free disk space on the system, enter the following command:

   -     # df -k

   The following table shows the approximate disk space requirements for software files for each installation type:

   Installation Type | Requirement for Software Files (GB)
   --- | ---
   Enterprise Edition | at least 1.5
   Standard Edition | at least 1.5
   Custom (maximum) | at least 1.5

5. To determine whether the system architecture can run the software, enter the following command:

       # grep "model name" /proc/cpuinfo

   Note: This command displays the processor type. If you intend to install on a 64-bit architecture, then verify that the processor architecture matches the requirement for the Oracle software release that you want to install.

## 2.6 Checking the Network Requirements

Check that you have the networking hardware and internet protocol (IP) addresses required for an Oracle Real Application Clusters installation.

Note: For the most up-to-date information about supported network protocols and hardware for RAC installations, refer to the Certify pages on the OracleMetaLink Web site at
    http://metalink.oracle.com

Network Hardware Requirements

Each node in the cluster must meet the following requirements:

- Each node must have at least two network adapters: one for the public network interface, and one for the private network interface (the interconnect).

- The public interface names associated with the network adapters for each network must be the same on all nodes, and the private interface names associated with the network adaptors should be the same on all nodes.

  For example: With a two-node cluster, you cannot configure network adapters on `node1` with `eth0` as the public interface, but on `node2` have `eth1` as the public interface. Public interface names must be the same, so you must configure eth0 as public on both nodes. You should configure the private interfaces on the same network adapters as well. If `eth1` is the private interface for `node1`, then `eth1` should be the private interface for `node2`.

- For increased reliability, configure redundant public and private network adapters for each node.

- For the public network, each network adapter must support TCP/IP.

- For the private network, the interconnect must support the user datagram protocol (UDP) using high-speed network adapters and switches that support TCP/IP (Gigabit Ethernet or better recommended).

  Note: UDP is the default interconnect protocol for RAC, and TCP is the interconnect protocol for Oracle Clusterware. Token-Ring is not supported for the interconnect.

- For the private network, the endpoints of all designated interconnect interfaces must be completely reachable on the network. There should be no node that is not connected to every private network. You can test whether an interconnect interface is reachable using a `ping` command.

Network Parameter Requirements

If you are using NFS for your shared storage, then you must set the values for the NFS buffer size parameters `rsize` and `wsize` to at least 16384. Oracle recommends that you use the value 32768.

For example, if you decide to use rsize and wsize buffer settings with the value 16384, then update the `/etc/fstab` file on each node with an entry similar to the following:

    clusternode:/vol/DATA/oradata  /home/oracle/netapp     nfs     rw,bg,vers=3,tcp,hard,nointr,timeo=600,rsize=32768,wsize=32768,actimeo=0  1 2

### 2.6.1 IP Address Requirements

Before starting the installation, you must have the following IP addresses available for each node:

- An IP address with an associated network name registered in the domain name service (DNS) for the public interface. If you do not have an available DNS, then record the network name and IP address in the system hosts file, `/etc/hosts`.

- One virtual IP (VIP) address with an associated network name registered in DNS. If you do not have an available DNS, then record the network name and VIP address in the system hosts file, `/etc/hosts`. Select an address for your VIP that meets the following requirements:

  - The IP address and network name are currently unused

  - The VIP is on the same subnet as your public interface

  Before installation, check that the default gateway can be accessed by a `ping` command. During installation, OUI uses the `ping` command to ensure that the VIP is reachable. To find the default gateway, use the `route` command, as described in your operating system's help utility. After installation, configure clients to use either the VIP address, or the network name associated with the VIP. If a node fails, then the node's virtual IP address fails over to another node.

- A private IP address with a host name for each private interface

  Oracle recommends that you use private network IP addresses for these interfaces (for example: 10.*.*.* or 192.168.*.*). Use the `/etc/hosts` file on each node to associate private network names with private IP addresses.

For example, with a two node cluster where each node has one public and one private interface, you might have the configuration shown in the following table for your network interfaces, where the hosts file is `/etc/hosts`:

Node | Interface Name | Type | IP Address | Registered In
--- | --- | --- | --- | ---
rac1 | rac1 | Public | 143.46.43.100 | DNS (if available, else the hosts file)
rac1 | rac1-vip | Virtual | 143.46.43.104 | DNS (if available, else the hosts file)
rac1 | rac1-priv | Private | 10.0.0.1 | Hosts file
rac2 | rac2 | Public | 143.46.43.101 | DNS (if available, else the hosts file)
rac2 | rac2-vip | Virtual | 143.46.43.105 | DNS (if available, else the hosts file)
rac2 | rac2-priv | Private | 10.0.0.2 | Hosts file

To enable VIP failover, the configuration shown in the preceding table defines the public and VIP addresses of both nodes on the same subnet, 143.46.43. When a node or interconnect fails, then the associated VIP is relocated to the surviving instance, enabling fast notification of the failure to the clients connecting through that VIP. If the application and client are configured with transparent application failover options, then the client is reconnected to the surviving instance.

### 2.6.2 Node Time Requirements

Before starting the installation, ensure that each member node of the cluster is set as closely as possible to the same date and time. Oracle strongly recommends using the Network Time Protocol feature of most operating systems for this purpose, with all nodes using the same reference Network Time Protocol server.

### 2.6.3 Configuring the Network Requirements

To verify that each node meets the requirements, follow these steps:

1. If necessary, install the network adapters for the public and private networks and configure them with either public or private IP addresses.

2. Register the host names and IP addresses for the public network interfaces in DNS.

3. For each node, register one virtual host name and IP address in DNS.

4. For each private interface on every node, add a line similar to the following to the `/etc/hosts` file on all nodes, specifying the private IP address and associated private host name:

       10.0.0.1     rac1-priv1

5. To identify the interface name and associated IP address for every network adapter, enter the following command:

       # /sbin/ifconfig

   From the output, identify the interface name and IP address for all network adapters that you want to specify as public or private network interfaces.

   Note: When you install Oracle Clusterware and RAC, you will require this information.

6. To prevent network hangs with failovers from public to virtual IP addresses with RAC databases using NAS devices or NFS mounts, enter the following command as root to enable the Name Service Cache Daemon (`nscd`):

       # /sbin/service  nscd start

## 2.7 Checking the Network Setup with CVU

As the `oracle` user, enter a command using the following syntax to verify node connectivity among all of the nodes for which your cluster is configured:

    /mountpoint/crs/Disk1/cluvfy/runcluvfy.sh comp nodecon -n node_list [-verbose]

In the preceding syntax example, the variable `node_list` is a comma-separated list of nodes in your cluster. This command detects all the network interfaces available on the cluster nodes, and verifies the connectivity among all the nodes through the network interfaces it finds.

Select the option `-verbose` to receive progress updates as the CVU performs its system checks, and detailed reporting of the test results.

For example, to verify node connectivity on a two-node cluster with nodes `node1` and `node2`, with the mountpoint `/dev/dvdrom`, and with updates and a summary of the verification checks the CVU performs, enter the following command:

    /dev/dvdrom/crs/Disk1/cluvfy/runcluvfy.sh comp nodecon -n node1,node2 -verbose

Note: You can use this command to obtain a list of all the interfaces available on the nodes that are suitable for use as VIPs, as well as a list of private interconnects that are connecting successfully on all nodes.

## 2.8 Identifying Software Requirements

Depending on the products that you intend to install, verify that the following software is installed on the system. To check these requirements refer to the section "Checking the Software Requirements", following this section.

Note: Oracle Universal Installer performs checks on your system to verify that it meets the listed requirements. To ensure that these checks pass, verify the requirements before you start Oracle Universal Installer.

The following is the list of supported Linux versions and requirements at the time of release:

- Software Requirements List for x86 (32-bit) Platforms

- Software Requirements List for x86 (64-bit) Platforms

- Software Requirements List for Linux on Itanium

- Software Requirements List for Linux on POWER

- Software Requirements list for IBM zSeries Based Linux

### 2.8.1 Software Requirements List for x86 (32-bit) Platforms

Table 2-1 Linux x86 (32-bit) System Requirements

Item | Requirement
--- | ---
Operating system x86 | Red Hat Enterprise Linux AS/ES 3 (Update 3 or later) Red Hat Enterprise Linux AS/AS 4 (Update 1 or later) SUSE Linux Enterprise Server 9 (Service Pack 2 or later)
Kernel version | The system must be running the following kernel version (or a later version): Red Hat Enterprise Linux 3 (Update 4): 2.4.21-27.EL Red Hat Enterprise Linux 4 (Update 1): 2.6.9-11.EL SUSE Linux Enterprise Server 9 (Service Pack 2): 2.6.5-7.97
Red Hat Enterprise Linux 3 (Update 2) Packages | The following packages (or later versions) must be installed:
    binutils-2.14
    compat-db-4.0.14-5
    compat-gcc-7.3-2.96.128
    compat-gcc-c++-7.3-2.96.128
    compat-libstdc++-7.3-2.96.128
    compat-libstdc++-devel-7.3-2.96.128
    gcc-3.2
    glibc-2.3.2-95.27
    make-3.79
    openmotif-2.2.3
    setarch-1.3-1
Red Hat Enterprise Linux 4 (Update 1) Packages | The following packages (or later versions) must be installed:
    binutils-2.15.92.0.2-10.EL4
    compat-db-4.1.25-9
    control-center-2.8.0-12
    gcc-3.4.3-9.EL4
    gcc-c++-3.4.3-9.EL4
    glibc-2.3.4-2
    glibc-common-2.3.4-2
    gnome-libs-1.4.1.2.90-44.1
    libstdc++-3.4.3-9.EL4
    libstdc++-devel-3.4.3-9.EL4
    make-3.80-5
Note: `openmotif21-2.1.30-11.RHEL4.2` is required to install Oracle demos. GNU Compiler Collection (`GCC`) 2.96 is not supported on Red Hat Enterprise Linux 4.0.
SUSE Linux Enterprise Server 9 (Service Pack 2) Packages |
    gcc-3.3
    gcc-c++-3.3.3-43
    glibc-2.3.3-98.28
    libaio-0.3.98-18
    libaio-devel-0.3.98-18
    make-3.80
    openmotif-libs-2.2.2-519.1
PL/SQL native compilation, Pro*C/C++, Oracle Call Interface, Oracle C++ Call Interface, Oracle XML Developer's Kit (XDK) | The version of GNU C and C++ compilers listed previously for your distribution is supported for use with these products.
- Oracle JDBC/OCI Drivers | On x86-64 systems, you can use the following optional JDK version with the Oracle JDBC/OCI drivers; however, it is not required for the installation: JDK 1.4.2_03 with the JNDI extension
      http://www.sun.com/java
Oracle Real Application Clusters | For a cluster file system, use one of the following options: Red Hat 3: Oracle Cluster File System (OCFS) Version 1.0.11-1 or later OCFS requires the following kernel packages:
    ocfs-support
    ocfs-tools
    ocfs-kernel_version
In the preceding list, the variable `kernel_version` represents the kernel version of the operating system on which you are installing OCFS. Note: OCFS is required only if you want to use a cluster file system for database file storage. If you want to use Automatic Storage Management or raw devices for database file storage, then you do not need to install OCFS. Obtain OCFS kernel packages, installation instructions, and additional information about OCFS from the following URL:
    http://oss.oracle.com/projects/ocfs/
Red Hat 4: Oracle Cluster File System 2 (OCFS2) Version 1.0.1-1 or later For information about Oracle Cluster File System version 2, refer to the following Web site:
    http://oss.oracle.com/projects/ocfs2/
For OCFS2 certification status, refer to the Certify page on OracleMetaLink. SUSE 9: Oracle Cluster File System 2 (OCFS2) OCFS2 is bundled with SuSE Linux Enterprise Server 9, Service Pack 2 or higher. If you are running SUSE 9,then ensure that you are upgraded to the latest kernel (Service Pack 2 or higher), and ensure that you have installed the packages `ocfs2-tools` and `ocfs2console`. For OCFS2 certification status, refer to the Certify page on OracleMetaLink.

### 2.8.2 Software Requirements List for x86 (64-bit) Platforms

Table 2-2 Linux x86 (64-bit) System Requirements

Item | Requirement
--- | ---
Operating systems x86 (64-bit) | Red Hat Enterprise Linux AS/ES 3 (Update 4 or later) Red Hat Enterprise Linux AS/ES 4 (Update 1 or later) SUSE Linux Enterprise Server 9 (Service Pack 2 or later)
Kernel version x86 | The system must be running one of the following kernel versions (or a later version): Red Hat Enterprise Linux 3 (Update 4): 2.4.21-27.EL Note: This is the default kernel version. Red Hat Enterprise Linux 4 (Update 1): 2.6.9-11.EL SUSE Linux Enterprise Server 9 (Service Pack 2): 2.6.5-7.201
Red Hat Enterprise Linux 3 (Update 4) Packages | The following packages (or later versions) must be installed:
    make-3.79.1-17
    compat-db 4.0.14-5.1
    control-center-2.2.0.1-13
    gcc-3.2.3-47
    gcc-c++-3.2.3-47
    gdb-6.1post-1.20040607.52
    glibc-2.3.2-95.30
    glibc-common-2.3.2-95.30
    glibc-devel-2.3.2-95.30
    glibc-devel-2.3.2-95.20 (32 bit)
    glibc-devel-2.3.4-2.13.i386 (32-bit)
    compat-db-4.0.14-5
    compat-gcc-7.3-2.96.128
    compat-gcc-c++-7.3-2.96.128
    compat-libstdc++-7.3-2.96.128
    compat-libstdc++-devel-7.3-2.96.128
    gnome-libs-1.4.1.2.90-34.2 (32 bit)
    libstdc++-3.2.3-47
    libstdc++-devel-3.2.3-47
    openmotif-2.2.3-3.RHEL3
    sysstat-5.0.5-5.rhel3
    setarch-1.3-1
    libaio-0.3.96-3
    libaio-devel-0.3.96-3
Note: XDK is not supported with gcc on Red Hat Enterprise Linux 3.
Red Hat Enterprise Linux 4 (Update 1):Packages | The following packages (or later versions) must be installed:
    binutils-2.15.92.0.2-10.EL4
    binutils-2.15.92.0.2-13.0.0.0.2.x86_64
    compat-db-4.1.25-9
    control-center-2.8.0-12
    gcc-3.4.3-9.EL4
    gcc-c++-3.4.3-9.EL4
    glibc-2.3.4-2
    glibc-common-2.3.4-2
    gnome-libs-1.4.1.2.90-44.1
    libstdc++-3.4.3-9.EL4
    libstdc++-devel-3.4.3-9.EL4
    make-3.80-5
Note: `XDK` is not supported with `gcc` on Red Hat Enterprise Linux 4.
SUSE Linux Enterprise Server 9 Packages | The following packages (or later versions) must be installed:
    binutils-2.15.90.0.1.1-32.5
    gcc-3.3.3-43.24
    gcc-c++-3.3.3-43.24
    glibc-2.3.3-98.28
    gnome-libs-1.4.1.7-671.1
    libstdc++-3.3.3-43.24
    libstdc++-devel-3.3.3-43.24
    make-3.80-184.1
PL/SQL native compilation, Pro*C/C++, Oracle Call Interface, Oracle C++ Call Interface, Oracle XML Developer's Kit (XDK) | Intel C++ Compiler 8.1 or later and the version of GNU C and C++ compilers listed previously for the distribution are supported for use with these products. Note: Intel C++ Compiler v8.1 or later is supported. However, it is not required for installation. On Red Hat Enterprise Linux 3, Oracle C++ Call Interface (OCCI) is supported with version 2.2 of the GNU C++ compiler. This is the default compiler version. OCCI is also supported with Intel Compiler v8.1 with gcc 3.2.3 standard template libraries. On Red Hat Enterprise Linux 4.0, OCCI does not support GCC 3.4.3. To use OCCI on Red Hat Enterprise Linux 4.0, you need to install GCC 3.2.3. Oracle XML Developer's Kit is not supported with GCC on Red Hat Linux 4.0. It is supported only with Intel C++ Compiler (ICC).
Oracle JDBC/OCI Drivers | You can use the following optional JDK versions with the Oracle JDBC/OCI drivers; however, they are not required for the installation: Sun JDK 1.5.0 (64-bit) Sun JDK 1.5.0 (32-bit) Sun JDK 1.4.2_09 (32-bit)
Oracle Real Application Clusters | For a cluster file system, use one of the following options: Red Hat 3: Oracle Cluster File System (OCFS) Version 1.0.13-1 or later OCFS requires the following kernel packages:
    ocfs-support
    ocfs-tools
    ocfs-kernel_version
In the preceding list, the variable `kernel_version` represents the kernel version of the operating system on which you are installing OCFS. Note: OCFS is required only if you want to use a cluster file system for database file storage. If you want to use Automatic Storage Management or raw devices for database file storage, then you do not need to install OCFS. Obtain OCFS kernel packages, installation instructions, and additional information about OCFS from the following URL:
    http://oss.oracle.com/projects/ocfs/
Red Hat 4: Oracle Cluster File System 2 (OCFS2) Version 1.0.1-1 or later For information about Oracle Cluster File System version 2, refer to the following Web site:
    http://oss.oracle.com/projects/ocfs2/
For OCFS2 certification status, refer to the Certify page on OracleMetaLink. SUSE 9: Oracle Cluster File System 2 (OCFS2) OCFS2 is bundled with SuSE Linux Enterprise Server 9, Service Pack 2 or higher. If you are running SUSE9, then ensure that you are upgraded to the latest kernel (Service Pack 2 or higher), and ensure that you have installed the packages `ocfs2-tools` and `ocfs2console`. For OCFS2 certification status, refer to the Certify page on OracleMetaLink.

### 2.8.3 Software Requirements List for Linux on Itanium

Table 2-3 Linux Itanium (64-bit) System Requirements

Item | Requirement
--- | ---
Operating systems | Red Hat Enterprise Linux AS/ES 3.0 (Update 3 or later) Red Hat Enterprise Linux AS/ES 4.0 (Update 1 or later) SUSE Linux Enterprise Server 9.0 (Service Pack 2 or later)
Kernel version Itanium | The system must be running one of the following kernel versions (or a later version): Red Hat Enterprise Linux 3.0: 2.4.21-278.EL Red Hat Enterprise Linux 4.0: 2.6.9-11.EL SUSE Linux Enterprise Server 9: 2.6.5-139
Packages Red Hat Enterprise Linux 3.0 |
    make-3.79.1-17
    control-center-2.2.0.1-13
    gcc-3.2.3-47
    gcc-c++-3.2.3-47
    gdb-6.1post-1.20040607.52
    glibc-2.3.2-95.30
    glibc-common-2.3.2-95.30
    glibc-devel-2.3.2-95.30
    glibc-devel-2.3.2-95.20 (32 bit)
    glibc-devel-2.3.4-2.13.i386 (32-bit)
    compat-db-4.0.14-5.1
    compat-gcc-7.3-2.96.128
    compat-gcc-c++-7.3-2.96.128
    compat-libstdc++-7.3-2.96.128
    compat-libstdc++-devel-7.3-2.96.128
    gnome-libs-1.4.1.2.90-34.2 (32 bit)
    libstdc++-3.2.3-47
    libstdc++-devel-3.2.3-47
    openmotif-2.2.3-3.RHEL3
    sysstat-5.0.5-5.rhel3
    setarch-1.3-1
    libaio-0.3.96-3
    libaio-devel-0.3.96-3
Packages Red Hat Enterprise Linux 4.0 |
    binutils-2.15.92.0.2-10.EL4
    compat-db-4.1.25-9
    control-center-2.8.0-12
    gcc-3.4.3-9.EL4
    gcc-c++-3.4.3-9.EL4
    glibc-2.3.4-2
    glibc-common-2.3.4-2
    gnome-libs-1.4.1.2.90-44.1
    libstdc++-3.4.3-9.EL4
    libstdc++-devel-3.4.3-9.EL4
    make-3.80-5
Packages SUSE Linux Enterprise Server 9 |
    gcc-3.3.3
    gcc-c++-3.3.3
    glibc-2.3.3
    libaio-0.3.102-1.2ia64
    libaio-devel-0.3.102-1.2ia64
    make-3.80
PL/SQL native compilation, Pro*C/C++, Oracle Call Interface, Oracle C++ Call Interface, Oracle XML Developer's Kit (XDK) | Intel C++ Compiler 8.1 or later and the version of GNU C and C++ compilers listed previously for the distribution are supported for use with these products. Note: Intel C++ Compiler v8.1 or later is supported. However, it is not required for installation. On Red Hat Enterprise Linux 3, OCCI is supported with version 3.2 of the GNU C++ compiler. This is the default compiler version. OCCI is also supported with Intel Compiler v8.1 with gcc 3.2.3 standard template libraries. Oracle XML Developer's Kit is not supported with GCC on Red Hat Linux 4.0. It is supported only with Intel C++ Compiler (ICC). On Red Hat Enterprise Linux 4.0, Oracle C++ Call Interface (OCCI) does not support GCC 3.4.3. To use OCCI on Red HatEnterprise Linux 4.0, you must install GCC 3.2.3.
Oracle JDBC/OCI Drivers | You can use the following optional JDK version with the Oracle JDBC/OCI drivers; however, it is not required for the installation: JDK 1.4.2 with the JNDI extension Note: JDK 1.4.2 is installed with this release.
Oracle Real Application Clusters | For a cluster file system, use one of the following options: Oracle Cluster File System (OCFS) Version 1.0.13-1 or later for SUSE Linux Enterprise Server 8 on Itanium systems Version 1.0.11-1 or later for other installations OCFS requires the following kernel packages:
    ocfs-support
    ocfs-tools
    ocfs-kernel_version
In the preceding list, the variable `kernel_version` represents the kernel version of the operating system on which you are installing OCFS. Note: OCFS is required only if you want to use a cluster file system for database file storage. If you want to use Automatic Storage Management or raw devices for database file storage, then you do not need to install OCFS. Obtain OCFS kernel packages, installation instructions, and additional information about OCFS from the following URL:
    http://oss.oracle.com/projects/ocfs/
Oracle Cluster File System 2 (OCFS2) For information about Oracle Cluster File System version 2, refer to the following Web site:
    http://oss.oracle.com/projects/ocfs2/
For OCFS2 certification status, refer to the Certify page on OracleMetaLink. In addition, if you want to use the support library for Automatic Storage Management (ASMLIB), then install the following ASMLIB kernel package for your distribution: Red Hat Enterprise Linux 3.0:
    oracleasm 2.4.21-27.EL-1.0.4-2.ia64.rpm
Red Hat Enterprise Linux 4.0:
    oracleasm 2.6.9-11.EL-2.0.0-1.ia64.rpm
Obtain ASMLIB kernel packages from the following URL:
    http://oss.oracle.com/projects/oracleasm/

### 2.8.4 Software Requirements List for Linux on POWER

Table 2-4 Linux on POWER System Requirements

Item | Requirement
--- | ---
Operating Systems Linux on POWER | Red Hat Enterprise Linux AS/ES 4 (Update 1 or later) SUSE Linux Enterprise Server 9 (Service Pack 2 or later)
Kernel version Linux on Power | Red Hat Enterprise Linux 4 (Update 1): 2.6.9-11.EL SUSE Linux Enterprise Server 9: Linux 2.6.5-7.191-pseries64
Packages Red Hat Enterprise Linux 4 |
    Gmake-3.80-5
    gcc-3.4.3-22.1
    gcc-ppc32-3.4.3-22.1
    gcc-c++-3.4.3-22.1
    gcc-c++-ppc32-3.4.3-22.1
    glibc-2.3.4-2.9
    glibc-2.3.4-29 (64-Bit)
    libgcc-3.4.3-9.EL4
    libgcc-3.4.3-9.EL4.ppc64.rp
    libstdc++-3.4.3-9.EL4
    libstdc++-devel-3.4.3-9.EL4
    libaio-0.3.103-3
    libaio-0.3.103-3 (64-Bit)
    libaio-devel-0.3.103-3 (64-Bit)
    compat-libstdc++-33-3.2.3-47.3
    binutils-2.15.92.0.2-13
Packages SUSE Linux Enterprise Server 9: |
    gcc-3.3.3-43.34
    gcc-64bit-9-200505240008
    gcc-c++-3.3.3-43.34
    glibc-2.3.3-98.47
    glibc-64bit-9-200506062240
    libgcc-3.3.3-43.34
    libgcc (64-bit) 9-200505240008
    libstdc++-3.3.3-43.34
    libstdc++-devel-3.3.3-43.34
    libaio-0.3.102-1.2
    libaio-64bit-9-200502241152
    libaio-devel-0.3.102-1.2
    libaio-devel-0.3.102-1.2 (64-bit)
    Gmake-3.80-184.1
    binutils-2.15.90.0.1.1-32.10
    binutils-64bit-9-200505240008
C/C++ Runtime Environment | Download the IBM XL C/C++ Advanced Edition V7.0.1 for Linux Runtime Environment Component for free without any license requirement from the following link: `http://www-1.ibm.com/support/docview.wss?rs=2030&context=SSJT9L&context=SSENT9&context=SSEP5D&dc=D400&dc=D410&dc=D420&dc=D430&q1=Run-time+Environment+Component&uid=swg24007906&loc=en_US&cs=utf-8&lang=en` You must also download and install the XL Optimization Libraries component from this link.
PL/SQL native compilation, Pro*C/C++, Oracle Call Interface, Oracle C++ Call Interface, Oracle XML Developer's Kit (XDK) | The version of C and C++ compilers listed previously for your distribution is supported for use with these products Note: IBM XL C/C++ compiler version 7.0 or later is also supported. If the IBM XL C/C++ Advanced Edition V7.0.1 for Linux on POWER compiler is to be used for Oracle user applications, then the required version is V7.0.1 or higher. For download information and updates, refer to the following link: `http://www-306.ibm.com/software/awdtools/xlcpp/features/linux/` If the IBM XL C/C++ Advanced Edition V7.0.1 for Linux on POWER compiler is installed, then the IBM XL C/C++ Advanced Edition V7.0.1 for Linux Runtime Environment Component is installed automatically.
Pro*COBOL | The following products are certified for use with Pro*COBOL: Micro Focus Server Express 4.0 SP 2 (for SLES 9)
Pro*FORTRAN | XL Fortran Advanced Edition V9.1.1 (or later) for Linux
Oracle JDBC/OCI Drivers | You can use the following optional JDK versions with the Oracle JDBC/OCI drivers; however, they are not required for the installation: IBM Java 1.4.2 64-bit (SR1a) or later IBM Java 1.4.2 32-bit (SR1a) or later IBM Java 1.3.1 32-bit (SR8) or later (for SLES 9 only) Note: By default, JDK 1.4.2 32-bit is installed with this release.
Oracle Real Application Clusters | IBM General Parallel File System (GPFS), version 2.3.0.6

### 2.8.5 Software Requirements list for IBM zSeries Based Linux

Table 2-5 IBM zSeries Based Linux System Requirements

Item | Requirement
--- | ---
Operating system | SUSE Linux Enterprise Server 9 (Service Pack 2 or later)
Kernel version |
Packages |
    gcc-3.3.3-43.34
    gcc-c++-3.3.3-43.34
    glibc 2.3.3-98.47
    libaio 0.3.102-1.2
    libaio devel 0.3.102-1.2
    libgcc-3.3.3-43.34
    libgcc (64-bit) unknown
    libgcc 3.3.3-43.34
    libstdc++ 3.3.3-43.34
    libstdc++ devel 3.3.3-43.34
    make-3.80-184.1
Pro*COBOL | Microfocus Server Express 4.0 SP 2
Oracle JDBC/OCI Drivers | You can use the following optional JDK versions with the Oracle JDBC/OCI drivers; however, they are not required for the installation: IBM SDK 1.5 or later IBM SDK1.4.2 (64-bit) IBM SDK 1.3.1 (31-bit) IBM SDK 1.4.2 (31-bit) Note: By default, JDK 1.4.2 32-bit is installed with this release.

## 2.9 Checking the Software Requirements

To ensure that the system meets these requirements, follow these steps:

1. To determine which distribution and version of Linux is installed, enter the following command:

       # cat /etc/issue

   Note: Only the distributions and versions listed in the table for the hardware platform on which you are installing are supported. Installation on other distributions of Linux are not supported.

2. To determine whether the required kernel errata is installed, use the following procedure for your Linux distribution:

   Red Hat Enterprise Linux systems

   Enter the following command:

       # uname -r
       2.6.9-11.EL

   In this example, the output shows the kernel version (`2.4.27`) and errata level (`27.EL`) on the system.

   Review the required errata level for your distribution. If the errata level is previous to the required minimum errata update, then install the latest kernel update. Kernel updates are available from Red Hat.

   SUSE Linux Enterprise Server Systems

   To determine whether the required kernel is installed on SUSE Linux Enterprise Server systems, enter the following command:

       # uname -r
       2.6.5-7.201

   In this example, the output shows the kernel version (2.6.5-7.201). If the kernel version is less than the required minimum update for your SUSE distribution, then contact SUSE for information about obtaining and installing the kernel updates.

3. To determine whether the required packages are installed, enter commands similar to the following:

       # rpm -q package_name

   If a package is not installed, then install it from your Linux distribution media or download the required package version from your Linux vendor's Web site.

4. To determine whether OCFS is installed, enter the following command:

       # rpm -qa | grep ocfs

   To ensure that OCFS is loaded, enter the following command:

       # /etc/init.d/ocfs status

   If you want to install the Oracle Database files on an OCFS file system and the packages are not installed, then download them from the following Web site. Follow the instructions listed with the kit to install the packages and configure the file system:

       http://oss.oracle.com/projects/ocfs/

   For Linux on POWER and IBM zSeries-based Linux, if you require a CSD for WebSphere MQ, then refer to the following Web site for download and installation information:

       http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006367

5. To use Huge Pages, or to accommodate the very large memory (VLM) window size on Red Hat Enterprise Linux 4, you must increase the default maximum size of the per-process locked memory. To increase the per-process max locked memory limit, add the following lines to the `/etc/security/limits.conf` file, where oracle is the user that administers the database:

       oracle soft memlock 3145728
       oracle hard memlock 3145728

6. To enable Oracle Database to use Huge Pages on Red Hat Enterprise Linux AS 2.1 (Itanium), SUSE Linux Enterprise Server 9, or Red Hat Enterprise Linux 4, set the value of the kernel parameter `vm.nr_hugepages` to specify the number of large pages that you want to reserve.

## 2.10 Configuring Kernel Parameters

Note: The kernel parameter and shell limit values shown in the following section are recommended values only. For production database systems, Oracle recommends that you tune these values to optimize the performance of the system. Refer to your operating system documentation for more information about tuning kernel parameters.

Verify that the kernel parameters shown in the following table are set to values greater than or equal to the recommended value shown. The procedure following the table describes how to verify and set the values.

On all cluster nodes, verify that the kernel parameters shown in the following table are set to values greater than or equal to the recommended value shown. The procedure following the table describes how to verify and set the values.

Parameter | Value | File
--- | --- | ---
semmsl semmns semopm semmni | 250 32000 100 128 | `/proc/sys/kernel/sem`
shmmax | Half the size of physical memory (in bytes) | `/proc/sys/kernel/shmmax`
shmmni | 4096 | `/proc/sys/kernel/shmmni`
shmall | 2097152 | `/proc/sys/kernel/shmall`
file-max | 65536 | `/proc/sys/fs/file-max`
ip_local_port_range | Minimum: 1024 Maximum: 65000 | `/proc/sys/net/ipv4/ip_local_port_range`
rmem_default | 262144 | `/proc/sys/net/core/rmem_default`
rmem_max | 1048576 | `/proc/sys/net/core/rmem_max`
wmem_default | 1048576 | `/proc/sys/net/core/wmem_default`
wmem_max | 262144 | `/proc/sys/net/core/wmem_max`

Note: If the current value for any parameter is greater than the value listed in this table, then do not change the value of that parameter.

To view the current value specified for these kernel parameters, and to change them if necessary, follow these steps:

1. Enter the commands shown in the following table to view the current values of the kernel parameters:

   Note: Make a note of the current values and identify any values that you must change.

   Parameter | Command
   --- | ---
   semmsl, semmns, semopm, and semmni | `# /sbin/sysctl -a | grep sem` This command displays the value of the semaphore parameters in the order listed.
   shmall, shmmax, and shmmni | `# /sbin/sysctl -a | grep shm`
   file-max | `# /sbin/sysctl -a | grep file-max`
   ip_local_port_range | `# /sbin/sysctl -a | grep ip_local_port_range` This command displays a range of port numbers.
   rmem_default, rmem_max, wmem_default, and wmem_max | `# /sbin/sysctl -a | grep net.core`

2. If the value of any kernel parameter is different from the recommended value, then complete the following process:

   Using any text editor, create or edit the `/etc/sysctl.conf` file, and add or edit lines similar to the following:

   Note: Include lines only for the kernel parameter values that you want to change. For the semaphore parameters (`kernel.sem`), you must specify all four values. However, if any of the current system parameter values are greater than the recommended values, then keep using the larger values.

       kernel.shmall = 2097152
       kernel.shmmax = 2147483648
       kernel.shmmni = 4096
       kernel.sem = 250 32000 100 128
       fs.file-max = 65536
       net.ipv4.ip_local_port_range = 1024 65000
       net.core.rmem_default = 262144
       net.core.rmem_max = 1048576
       net.core.wmem_default = 1048576
       net.core.wmem_max = 262144

   By specifying the values in the `/etc/sysctl.conf` file, they persist when you restart the system.

   On Red Hat systems, to have these changes take effect immediately so that you do not have to restart the system, enter the following command:

       /sbin/sysctl -p

3. Repeat steps 1 and 2 on all other nodes in the cluster.

   On SUSE systems only, enter the following command to cause the system to read the `/etc/sysctl.conf` file when it restarts:

       # /sbin/chkconfig boot.sysctl on

4. On SUSE Linux Enterprise Server 9.0 only, set the kernel parameter `disable_cap_mlock` as follows:

       disable_cap_mlock = 1

5. After updating the values of kernel parameters in the `/etc/sysctl.conf file`, either restart the computer, or run the command `sysctl -p` to make the changes in the `/etc/sysctl.conf` file available in the active kernel memory.

Setting Shell Limits for the oracle User

To improve the performance of the software on Linux systems, you must increase the following shell limits for the `oracle` user:

Shell Limit | Item in limits.conf | Hard Limit
--- | --- | ---
Maximum number of open file descriptors | `nofile` | 65536
Maximum number of processes available to a single user | `nproc` | 16384

To increase the shell limits:

1. Add the following lines to the `/etc/security/limits.conf` file:

       oracle              soft    nproc   2047
       oracle               hard    nproc   16384
       oracle               soft    nofile  1024
       oracle               hard    nofile  65536

2. Add or edit the following line in the `/etc/pam.d/login` file, if it does not already exist:

       session    required     /lib/security/pam_limits.so

3. Depending on the `oracle` user's default shell, make the following changes to the default shell startup file:

   - For the Bourne, Bash, or Korn shell, add the following lines to the `/etc/profile` file (or the file on SUSE systems)`/etc/profile.local`:

         if [ $USER = "oracle" ]; then
                 if [ $SHELL = "/bin/ksh" ]; then
                       ulimit -p 16384
                       ulimit -n 65536
                 else
                       ulimit -u 16384 -n 65536
                 fi
         fi

   - For the C shell (`csh` or `tcsh`), add the following lines to the `/etc/csh.login` file (or the file on SUSE systems)`/etc/csh.login.local`:

         if ( $USER == "oracle" ) then
                 limit maxproc 16384
                 limit descriptors 65536
         endif

4. Repeat this procedure on all other nodes in the cluster.

Refer to the "Identifying Required Software Directories" section to continue.

## 2.11 Checking the Hardware and Operating System Setup with CVU

As the `oracle` user, use the following command syntax to start Cluster Verification Utility (CVU) stage verification to check hardware and operating system setup:

    /mountpoint/crs/Disk1/cluvfy/runcluvfy.sh stage –post hwos –n node_list [-verbose]

In the preceding syntax example, replace the variable `node_list` with the names of the nodes in your cluster, separated by commas. For example, to check the hardware and operating system of a two-node cluster with nodes `node1` and `node2`, with the mountpoint `/dev/dvdrom/` and with the option to limit the output to the test results, enter the following command:

    /dev/dvdrom/crs/Disk1/cluvfy/runcluvfy.sh stage –post hwos –n node1,node2

Select the option `-verbose` to receive detailed reports of the test results, and progress updates about the system checks performed by Cluster Verification Utility.

## 2.12 Checking the Operating System Requirements Setup with CVU

As the `oracle` user, use the following command syntax to check if your system meets the operating system requirement pre-installation tasks:

    /mountpoint/crs/Disk1/cluvfy/runcluvfy.sh comp sys -n node_list -p {crs|database} -osdba osdba_group -orainv orainv_group -verbose

In the preceding syntax example:

- The variable mountpoint is the mountpoint of the Oracle 10g Release 2 (10.2) installation media

- The variable `node_list` is the list of nodes in your cluster, separated by commas

- The `-p` flag identifies either `crs` or `database`, and indicates that checks are performed for Oracle Clusterware or Oracle Database system requirements

- The variable `osdba_group` is the name of your OSDBA group, typically `dba`

- The variable `orainv_group` is the name of your Oracle Inventory group, typically `oinstall`

You can select the option `-verbose` to receive progress updates as the CVU performs its system checks, and detailed reporting of the test results.

For example, to perform a system check for an Oracle Clusterware installation on a two-node cluster with nodes `node1` and `node2`, with the OSDBA `dba` and Oracle inventory group `oinstall`, and with the media mountpoint `/dev/dvdrom/`, then enter the following command:

    /dev/dvdrom/crs/Disk1/cluvfy/runcluvfy.sh comp sys -n node1,node2 -p crs -osdba crs -orainv oinstall

## 2.13 Identifying Required Software Directories

You must identify or create the following directories for the Oracle software, as follows:

- Oracle Base Directory

- Oracle Inventory Directory

- Oracle Clusterware Home Directory

- Oracle Home Directory

The following subsections describe the requirements for these directories.

Oracle Base Directory

The Oracle base directory acts as a top-level directory for Oracle software installations. Optimal Flexible Architecture (OFA) guidelines recommend that you use a path similar to the following for the Oracle base directory:

    /mount_point/app/oracle_sw_owner

In this example:

- `mount_point` is the mount point directory for the file system that will contain the Oracle software.

  The examples in this guide use `/u01` for the mount point directory. However, you could choose another mount point directory, `/oracle` or `/opt/oracle` for example.

- `oracle_sw_owner` is the operating system user name of the Oracle software owner, for example `oracle`.

You can use the same Oracle base directory for more than one installation or you can create separate Oracle base directories for different installations. If different operating system users install Oracle software on the same system, then each user must create a separate Oracle base directory. The following example Oracle base directories could all exist on the same system:

    /u01/app/oracle
    /u01/app/orauser
    /opt/oracle/app/oracle

The following sections describe how to identify existing Oracle base directories that might be suitable for your installation and how to create an Oracle base directory if necessary.

Regardless of whether you create an Oracle base directory or decide to use an existing one, you must set the ORACLE_BASE environment variable to specify the full path to the Oracle base directory.

Note: The Oracle base directory can be on a local file system or on an NFS file system on a certified NAS device. Do not create the Oracle base directory on an OCFS version 1 file system.

Oracle Inventory Directory

The Oracle Inventory directory (`oraInventory`) stores an inventory of all software installed on the system. It is required by, and shared by, all Oracle software installations on a single system. The first time you install Oracle software on a system, Oracle Universal Installer prompts you to specify the path to this directory. If you are installing the software on a local file system, then Oracle recommends that you choose the following path:

    oracle_base/oraInventory

If the Oracle base directory is located either on a cluster file system, or on a shared NFS file system on a NAS device, then you must place the Oracle Central Inventory directory on a local file system, privately mounted on each node, so that each node has a separate copy of the central inventory.

If you specify a shared location for the Oracle Central Inventory, then each node attempts to write to the same central inventory. This is not supported.

Oracle Universal Installer creates the directory that you specify, and sets the correct owner, group, and permissions for it. You do not need to create it.

Note: All Oracle software installations rely on the Oracle base directory. Make sure that you back it up regularly. Do not delete the Oracle base directory unless you have completely removed all Oracle software from the system.

Oracle Clusterware Home Directory

The Oracle Clusterware home directory is the directory where you choose to install the software for Oracle Clusterware. You must install Oracle Clusterware in a separate home directory. When you run Oracle Universal Installer, it prompts you to specify the path to this directory, as well as a name that identifies it. Oracle recommends that you specify a path similar to the following for the Oracle Clusterware home directory:

    /u01/app/oracle/product/crs

Note: Because you must change the permissions of all of the parent directories of the Oracle Clusterware home directory after installing the software to grant write access only to the `root` user, the Oracle Clusterware home directory must not be a subdirectory of the Oracle base directory.

Oracle Home Directory

The Oracle home directory is the directory where you choose to install the software for a particular Oracle product. You must install different Oracle products, or different releases of the same Oracle product, in separate Oracle home directories. When you run Oracle Universal Installer, it prompts you to specify the path to this directory, as well as a name that identifies it. The directory that you specify must be a subdirectory of the Oracle base directory. Oracle recommends that you specify a path similar to the following for the Oracle home directory:

    oracle_base/product/10.2.0/db_1

Oracle Universal Installer creates the directory path that you specify under the Oracle base directory. It also sets the correct owner, group, and permissions on it. You do not need to create this directory.

Caution: During the installation, you must not specify an existing directory that has predefined permissions applied to it as the Oracle home directory. If you do, then you may experience installation failure due to file and group ownership permission errors.

## 2.14 Identifying or Creating an Oracle Base Directory

Before starting the installation, you must either identify an existing Oracle base directory or if required, create one. This section contains information about the following:

- Identifying an Existing Oracle Base Directory

- Creating an Oracle Base Directory

Note: You can choose to create an Oracle base directory, even if other Oracle base directories exist on the system.

Identifying an Existing Oracle Base Directory

Existing Oracle base directories might not have paths that comply with OFA guidelines. However, if you identify an existing Oracle Inventory directory or existing Oracle home directories, you can usually identify the Oracle base directories, as follows:

- Identifying an existing Oracle Inventory directory

  Enter the following command on all nodes in the cluster to view the contents of the `oraInst.loc` file:

  On x86 and Itanium systems:

      # more /etc/oraInst.loc

  On IBM zSeries based systems:

      # more /var/opt/oracle/oraInst.loc

  If the `oraInst.loc` file exists, then the output from this command is similar to the following:

      inventory_loc=/u01/app/oracle/oraInventory
      inst_group=oinstall

  The `inventory_loc` parameter identifies the Oracle Inventory directory (`oraInventory`) on that system. The parent directory of the `oraInventory` directory is typically an Oracle base directory. In the previous example, `/u01/app/oracle` is an Oracle base directory.

- Identifying existing Oracle home directories

  Enter the following command on all nodes in the cluster to view the contents of the `oratab` file:

      # more /etc/oratab

  If the `oratab` file exists, then it contains lines similar to the following:

      *:/u03/app/oracle/product/10.2.0/db_1:N
      *:/opt/orauser/infra_904:N
      *:/oracle/9.2.0:N

  The directory paths specified on each line identify Oracle home directories. Directory paths that end with the user name of the Oracle software owner that you want to use are valid choices for an Oracle base directory. If you intend to use the `oracle` user to install the software, then you could choose one of the following directories from the previous example:

      /u03/app/oracle
      /oracle

  Note: If possible, choose a directory path similar to the first (`/u03/app/oracle`). This path complies with the OFA guidelines.

Before deciding to use an existing Oracle base directory for this installation, make sure that it satisfies the following conditions:

- It should not be on the same file system as the operating system.

- It must have an identical path on all nodes in the cluster, or it must be an NFS file system on a certified NAS device.

  If you are not using an NFS file system, then create identical Oracle base directories on the other nodes.

- It must have at least 1.5 GB free disk space on all the nodes in the cluster

  To determine the free disk space on the file system where the Oracle base directory is located, enter the following command:

      # df -h oracle_base_path

  When you are configuring the `oracle` user's environment in the section "Creating the Oracle Clusterware Home Directory", set the ORACLE_BASE environment variable to specify the directory you choose.

If an Oracle base directory does not exist on the system, or if you want to create an Oracle base directory, then refer to the following section.

Creating an Oracle Base Directory

Before you create an Oracle base directory, you must identify an appropriate file system. The Oracle base directory requires at least 1.5 GB of free disk space.

To identify an appropriate file system, follow these steps:

1. Use the `df -``h` command to determine the free disk space on each mounted file system.

2. From the display, identify a file system that has appropriate free space.

   Note: The Oracle base directory can be on a local file system or on an NFS file system on a certified NAS device. Do not create the Oracle base directory on an OCFS version 1 file system.

   The path to the Oracle base directory must be the same on all nodes.

3. Note the name of the mount point directory for the file system that you identified.

To create the Oracle base directory and specify the correct owner, group, and permissions for it, follow these steps:

1. Enter commands similar to the following to create the recommended subdirectories in the mount point directory that you identified, and to set the appropriate owner, group, and permissions on them:

       # mkdir -p /mount_point/app/oracle_sw_owner
       # chown -R oracle:oinstall /mount_point/app/oracle_sw_owner
       # chmod -R 775 /mount_point/app/oracle_sw_owner

   For example, if the mount point you identify is `/u01`, and `oracle` is the user name of the Oracle software owner, then the recommended Oracle base directory path is as follows:

       /u01/app/oracle

2. If necessary, repeat the commands listed in the previous step to create the same directory on the other nodes in the cluster.

3. When you configure the `oracle` user's environment later in this chapter, set the ORACLE_BASE environment variable to specify the Oracle base directory you have created in this task.

## 2.15 Creating the Oracle Clusterware Home Directory

Oracle Universal Installer (OUI) creates the Oracle Clusterware home directory for you. Ensure before you start the installation that you provide sufficient disk space on a file system for the Oracle Clusterware directory, and the parent directory of the Oracle Clusterware directory space is writable by the `oracle` user.

To identify an appropriate file system, follow these steps:

1. Use the `df -h` command to determine the free disk space on each mounted file system.

2. From the display, identify a file system that has at least 120 MB of free disk space.

   If you are using the same file system for the Oracle base directory, then this 120 MB of disk space is additional to the free disk space requirement that you identified previously.

   Note: The file system can be a local file system or an NFS file system on a certified NAS device. Do not create the Oracle Clusterware home directory on an OCFS version 1 file system.

   The path to the Oracle Clusterware home directory must be the same on all nodes.

3. Note the name of the mount point directory for the file system that you identified.

To create the Oracle Clusterware home directory and specify the correct owner, group, and permissions for it, follow these steps:

1. Enter commands similar to the following to create the recommended subdirectories in the mount point directory that you identified and set the appropriate owner, group, and permissions on them:

       # mkdir -p /mount_point/crs/oracle_sw_owner/product/10/app
       # chown -R root:oinstall /mount_point/crs
       # chmod -R 775 /mount_point/crs/oracle_sw_owner

   If the mount point you identified is `/u01`, then the recommended Oracle Clusterware home directory path is as follows:

       /u01/crs/oracle/product/10/crs

   Note: After installation, you should change permissions so that only the root user can write to the Oracle Clusterware home directory.

2. If necessary, repeat the commands listed in the previous step to create the same directory on the other nodes in the cluster.

3. Enter commands similar to the following to set the ORACLE_BASE and ORACLE_HOME environment variable in preparation for the Oracle Clusterware installation:

   - Bourne, Bash, or Korn shell:

         $ ORACLE_BASE=/u01/app/oracle
         $ ORACLE_HOME=/u01/crs/oracle/product/10/app
         $ export ORACLE_BASE
         $ export ORACLE_HOME

   - C shell:

         % setenv ORACLE_BASE /u01/app/oracle
         % setenv ORACLE_HOME /u01/crs/oracle/product/10/app

4. Enter the following commands to ensure that the TNS_ADMIN environment variable is not set:

   - Bourne, Bash, or Korn shell:

         $ unset TNS_ADMIN

   - C shell:

         % unsetenv TNS_ADMIN

5. To verify that the environment has been set correctly, enter the following commands:

       $ umask
       $ env | more

   Verify that the `umask` command displays a value of `22`, `022`, or `0022` and the environment variables that you set in this section have the correct values.

## 2.16 Checking the Configuration of the Hangcheck-timer Module

Before installing Oracle Real Application Clusters on Linux systems, verify that the hangcheck-timer module (`hangcheck-timer`) is loaded and configured correctly. `hangcheck-timer` monitors the Linux kernel for extended operating system hangs that could affect the reliability of a RAC node and cause a database corruption. If a hang occurs, then the module restarts the node in seconds.

You can use the `hangcheck_tick` and `hangcheck_margin` parameters to control the behavior of the module, as follows:

- The `hangcheck_tick` parameter defines how often, in seconds, the `hangcheck-timer` checks the node for hangs. The default value is 60 seconds.

- The `hangcheck_margin` parameter defines how long the timer waits, in seconds, for a response from the kernel. The default value is 180 seconds.

If the kernel fails to respond within the sum of the `hangcheck_tick` and `hangcheck_margin` parameter values, the `hangcheck-timer` module restarts the system. Using the default values, the node would be restarted if the kernel fails to respond within 240 seconds.

To determine which hangcheck module verification procedure to use:

1. Log in as root, and enter the following command to check the kernel version:

       # uname -a

2. If the output indicates that it is a 2.4 kernel (for example, 2.4.21-27.EL), then proceed to Verifying Hangcheck-timer Module on Kernel 2.4. If it is a 2.6 kernel (for example, 2.6.9-11.EL), then proceed to Verifying Hangcheck-timer Module on Kernel 2.6.

### 2.16.1 Verifying Hangcheck-timer Module on Kernel 2.4

For Red Hat Linux 3.0 and SUSE 8 systems, to verify that the `hangcheck-timer` module is running on every node:

1. Enter the following command on each node to determine which kernel modules are loaded:

       # /sbin/lsmod

2. If the `hangcheck-timer` module is not listed for any node, enter a command similar to the following to start the module on that node:

       # /sbin/insmod hangcheck-timer hangcheck_tick=30 hangcheck_margin=180

3. To confirm that the hangcheck module is loaded, enter the following command:

       # lsmod | grep hang

   The output should be similar to the following:

       hangcheck_timer         3289  0

4. To ensure that the module is loaded every time the system restarts, verify that the local system startup file contains the command shown in the previous step, or add it if necessary:

   - Red Hat:

     On Red Hat Enterprise Linux systems, add the command to the `/etc/rc.d/rc.local` file.

   - SUSE:

     On SUSE systems, add the command to the `/etc/init.d/boot.local` file.

### 2.16.2 Verifying Hangcheck-timer Module on Kernel 2.6

For Red Hat Linux 4.0 and SUSE 9 systems, to verify that the `hangcheck-timer` module is running on every node:

1. Enter the following command on each node to determine which kernel modules are loaded:

       # /sbin/lsmod

2. If the `hangcheck-timer` module is not listed for any node, then enter a command similar to the following to start the module located in the directories of the current kernel version:

       # insmod /lib/modules/kernel_version/kernel/drivers/char/hangcheck-timer.ko  hangcheck_tick=30 hangcheck_margin=180

   In the preceding command example, the variable `kernel_version` is the kernel version running on your system.

3. To confirm that the hangcheck module is loaded, enter the following command:

       # lsmod | grep hang

   The output should be similar to the following:

       hangcheck_timer         3289  0

4. To ensure that the module is loaded every time the system restarts, verify that the local system startup file contains the command shown in the previous step, or add it if necessary:

   - Red Hat:

     On Red Hat Enterprise Linux systems, add the command to the `/etc/rc.d/rc.local` file.

   - SUSE:

     On SUSE systems, add the command to the `/etc/init.d/boot.local` file.

## 2.17 Running the rootpre.sh Script for Installations on x86 (64-bit) Systems

If you plan to use Oracle Clusterware on x86 (64-bit) systems, then you must run the `rootpre.sh` script as the `root` user on all the nodes of the cluster. If you are installing on either Linux x86 (32-bit) or Linux Itanium (64-bit) systems, then you do not need to run the `rootpre.sh` script.

Use the following procedure on each cluster node to run the rootpre.sh script:

1. Log in as root.

2. Use a command similar to the following to change to the `rootpre` directory:

       # cd $mount_point/clusterware/rootpre

   The variable `mount_point` is the mount point of the installation media on your system.

3. Using the following command, run the `rootpre.sh` script:

       # ../rootpre.sh

## 2.18 Stopping Existing Oracle Processes for Upgrades or Co-existing Databases

Table 2-6 provides an overview of what you need to do if you have an existing Oracle database on the system where you plan to install Oracle Database 10g Release 2 (10.2). Review the table, and perform tasks as required.

See Also: Oracle Database Upgrade Guide for additional information about preparing for and performing upgrades.

Table 2-6 Overview of System Preparation for Upgrades or Co-existing Databases

Installation Scenario | What you need to do
--- | ---
Upgrading from Oracle Database 10g Release 1 (10.1) to 10g Release 2 (10.2) | No additional tasks. Refer to Installing Oracle 10g Release 2 on a System with Oracle 10g Release 1
installing Oracle Database 10g Release 2 (10.2) on a system to co-exist with Oracle Database 10g Release 1 (10.1) | No additional tasks. Refer to Installing Oracle 10g Release 2 on a System with Oracle 10g Release 1
Upgrading from Oracle9i Release 9.2 to Oracle Database 10g Release 2 (10.2) | Shut down the Global Service Daemon, and shut down a default listener on port 1521, if present. Refer to Installing Oracle 10g Release 2 on a System with Oracle9i Release 2
Installing Oracle Database 10g Release 2 (10.2) on a system to co-exist with Oracle9i Release 9.2 | Shut down a default listener on port 1521, if present, and shut down the Global Service Daemon. Refer to Installing Oracle 10g Release 2 on a System with Oracle9i Release 2

Installing Oracle 10g Release 2 on a System with Oracle 10g Release 1

If your system has an Oracle Database Release 10g Release 10. 1 installation, and you install an Oracle Database 10g Release 2 (10.2) either to coexist with or to upgrade the 10.1, then most installation types configure and start a default Oracle Net listener using TCP/IP port 1521 and the IPC key value EXTPROC. One of the following occurs:

- During a co-existing installation, Database Configuration Assistant (DBCA) automatically migrates the listener and related files from the 10.1 Oracle home to the 10.2 Oracle home.

- During an upgrade, Oracle Database Upgrade Assistant (DBUA) automatically locates the Oracle 10g release 1 (10.1) listener, and migrates it to Oracle 10g release 2.

Proceed to Chapter 3.

Installing Oracle 10g Release 2 on a System with Oracle9i Release 2

This section provides instructions for preparing

Explanation of Tasks If you are installing an Oracle Database 10g Release 2 (10.2) on a system with an existing Oracle9i Release 2 (9.2) database, and the Oracle Net listener process is using the same port or key value as the default used with the Oracle 10g Release 2 (10.2) installation, port 1521, then Oracle Universal Installer can only configure the new listener; it cannot start it. To ensure that the new listener process starts during the installation, you must shut down any existing listeners before starting Oracle Universal Installer. To do this, refer to "Shutting Down the Listener"

You must shut down the Global Services Daemon (GSD), because otherwise, during 10g Release 2 (10.2) installation, the Oracle9i Release 9.2 SRVM shared data is upgraded into an Oracle Cluster Registry that the 9.2 GSD will not be able to use. The 10.2 Oracle Clusterware installation starts a 10g Release 2 (10.2) GSD to serve the Oracle9i 9.2 clients. To do this, refer to "Shutting down the Global Services Daemon"

Shutting Down the Listener To determine whether an existing Oracle9i listener process is running and to shut it down if necessary, follow these steps:

1. Switch user to `oracle`:

       # su - oracle

2. Enter the following command to determine whether an Oracle9i listener process is running and to identify its name and the Oracle home directory in which it is installed:

       $ ps -ef | grep tnslsnr

   This command displays information about the Oracle Net listeners running on the system:

       ... oracle_home1/bin/tnslsnr LISTENER -inherit

   In this example, `oracle_home1` is the Oracle home directory where the listener is installed and `LISTENER` is the listener name.

   Note: If no Oracle Net listeners are running, then proceed to Chapter 3.

3. Set the ORACLE_HOME environment variable to specify the appropriate Oracle home directory for the listener:

   - Bourne, Bash, or Korn shell:

         $ ORACLE_HOME=oracle_home1
         $ export ORACLE_HOME

   - C or tcsh shell:

         % setenv ORACLE_HOME oracle_home1

4. Enter the following command to identify the TCP/IP port number and IPC key value that the listener is using:

       $ $ORACLE_HOME/bin/lsnrctl status listenername

   Note: If the listener uses the default name LISTENER, then you do not have to specify the listener name in this command.

5. Enter a command similar to the following to stop the listener process:

       $ $ORACLE_HOME/bin/lsnrctl stop listenername

6. Repeat this procedure to stop all listeners running on this system and on all other nodes in the cluster.

Shutting down the Global Services Daemon As the `oracle` user, on each node of the cluster, use the following syntax to shut down the GSD:

    $ cd 92_Oracle_home
    $ bin/gsdctl stop

In the preceding syntax example, the variable 92_Oracle_home is the Oracle9i Release 2 (9.2) database home.